home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / policy4.arc / POLICY4.TXT < prev   
Text File  |  1989-06-03  |  76KB  |  1,727 lines

  1.                             FidoNet Policy Document               Version 4.07
  2.                                                                   June 9, 1989
  3.  
  4.  
  5. This policy document has been accepted by vote of the FidoNet coordinator
  6. structure, and is the current FidoNet policy document until superceded.
  7.  
  8. (There are no differences between this version and 4.06 except the statement
  9. above.)
  10.  
  11.  
  12.  
  13. 1  Overview
  14.  
  15. This document establishes the policy for sysops who are members of the
  16. FidoNet organization of electronic bulletin board systems.  FidoNet is
  17. defined by a NodeList issued weekly by the International Coordinator.
  18.  
  19. Separate policy documents may be issued at the zone, region, or net level to
  20. provide additional detail on local procedures.  Ordinarily, these lower-level
  21. policies may not contradict this policy.  However, with the approval of the
  22. International Coordinator, local policy can be used to implement differences
  23. required due to local conditions.  These local policies may not place
  24. additional restrictions on members of FidoNet beyond those included in this
  25. document, other than enforcement of local mail periods.
  26.  
  27.  
  28.  
  29. 1.0  Language
  30.  
  31. The official language of FidoNet is English.  All documents must exist in
  32. English.  Translation into other languages is encouraged.
  33.  
  34.  
  35. 1.1  Introduction
  36.  
  37. FidoNet is an amateur electronic mail system.  As such, all of its partici-
  38. pants and operators are unpaid volunteers.  From its early beginning as a few
  39. friends swapping messages back and forth (1984), it now (1989) includes over
  40. 5,000 systems on six continents.
  41.  
  42. FidoNet is not a common carrier or a value-added service network and is a
  43. public network only in as much as the independent, constituent nodes may
  44. individually provide public access to the network on their system.
  45.  
  46. FidoNet is large enough that it would quickly fall apart of its own weight
  47. unless some sort of structure and control were imposed on it.  Multinet
  48. operation provides the structure. Decentralized management provides the
  49. control.  This document describes the procedures which have been developed to
  50. manage the network.
  51.  
  52.  
  53. 1.2  Organization
  54.  
  55. FidoNet systems are grouped on several levels, and administration is decen-
  56. tralized to correspond with these groupings.  This overview provides a
  57. summary of the structure; specific duties of the coordinator positions are
  58. given later in the document.
  59.  
  60. 1.2.1  Individual Systems and System Operators
  61.  
  62. The smallest subdivision of FidoNet is the individual system, corresponding
  63. to a single entry in the nodelist.  The system operator (sysop) formulates a
  64. policy for running the board and dealing with users.  The sysop must mesh
  65. with the rest of the FidoNet system to send and receive mail, and the local
  66. policy must be consistent with other levels of FidoNet.
  67.  
  68. 1.2.1.1  Users
  69.  
  70. The sysop is responsible for the actions of any user when they affect the
  71. rest of FidoNet.  (If a user is annoying, the sysop is annoying.)  Any
  72. traffic entering FidoNet via a given node, if not from the sysop, is consid-
  73. ered to be from a user and is the responsibility of the sysop.  (See section
  74. 2.1.3.)
  75.  
  76. 1.2.1.2  Points
  77.  
  78. A point is a FidoNet-compatible system that is not in the nodelist, but
  79. communicates with FidoNet through a node referred to as a bossnode.  A point
  80. is generally regarded in the same manner as a user, for example, the bossnode
  81. is responsible for mail from the point.  (See section 2.1.3.)  Points are
  82. addressed by using the bossnode's nodelist address; for example, a point
  83. system with a bossnode of 114/15 might be known as 114/15.12.  Mail destined
  84. for the point is sent to the bossnode, which then routes it to the point.
  85.  
  86. In supporting points, the bossnode makes use of a private net number which
  87. should not be generally visible outside of the bossnode-point relationship.
  88. Unfortunately, should the point call another system directly (to do a file
  89. request, for example), the private network number will appear as the caller's
  90. address.  In this way, points are different from users, since they operate
  91. FidoNet-compatible mailers which are capable of contacting systems other than
  92. the bossnode.
  93.  
  94.  
  95. 1.2.3  Networks and Network Coordinators
  96.  
  97. A network is a collection of nodes in a local geographic area, usually
  98. defined by an area of convenient telephone calling.  Networks coordinate
  99. their mail activity to decrease cost.
  100.  
  101. The Network Coordinator is responsible for maintaining the list of nodes for
  102. the network, and for forwarding netmail sent to members of the network from
  103. other FidoNet nodes.  The Network Coordinator may make arrangements to handle
  104. outgoing netmail, but is not required to do so.
  105.  
  106. The Network Coordinator is appointed by the Regional Coordinator.
  107.  
  108. 1.2.3.1  Network Routing Hubs
  109.  
  110. Network Routing Hubs exist only in some networks.  They may be appointed by
  111. the Network Coordinator, in order to assist in the management of a large net-
  112. work.  The exact duties and procedures are a matter for the Network Coordina-
  113. tor and the hubs to arrange, and will not be discussed here, except that a
  114. network coordinator cannot delegate responsibility to mediate disputes.
  115.  
  116. 1.2.4  Regions and Regional Coordinators
  117.  
  118. A region is a well-defined geographic area containing nodes which may or may
  119. not be combined into networks.  A typical region will contain many nodes in
  120. networks, and a few independent nodes which are not a part of any network.
  121.  
  122. The Regional Coordinator maintains the list of independent nodes in the
  123. region and accepts nodelists from the Network Coordinators in the region.
  124. These are compiled to create a regional nodelist, which is then sent to the
  125. Zone Coordinator.  A Regional Coordinator does not perform message-forwarding
  126. services for any nodes in the region.
  127.  
  128. Regional Coordinators are appointed by the Zone Coordinator.
  129.  
  130.  
  131. 1.2.5  Zones and Zone Coordinators
  132.  
  133. A zone is a large geographic area containing many regions, covering one or
  134. more countries and/or continents.
  135.  
  136. The Zone Coordinator compiles the nodelists from all of the regions in the
  137. zone, and creates the master nodelist and difference file, which is then
  138. distributed over FidoNet in the zone.  A Zone Coordinator does not perform
  139. message-forwarding services for any nodes in the zone.
  140.  
  141. Zone Coordinators are selected by the Regional Coordinators in that zone.
  142.  
  143.  
  144. 1.2.6  Zone Coordinator Council
  145.  
  146. In certain cases, the Zone Coordinators work as a council to provide advice
  147. to the International Coordinator.  The arrangement is similar to that between
  148. a president and advisors.  In particular, this council considers inter-zonal
  149. issues.  This includes, but is not limited to: working out the details of
  150. nodelist production, mediating inter-zonal disputes, and such issues not
  151. addressed at a lower level of FidoNet.
  152.  
  153.  
  154. 1.2.7  International Coordinator
  155.  
  156. The International Coordinator is the "first among equals" Zone Coordinator,
  157. and coordinates the joint production of the master nodelist by the Zone
  158. Coordinators.
  159.  
  160. The International Coordinator acts as the chair of the Zone Coordinator
  161. Council and as the overseer of elections -- arranging the announcement of
  162. referenda, the collection and counting of the ballots, and announcing the
  163. results for those issues that affect FidoNet as a whole.
  164.  
  165. The International Coordinator is selected by the Zone Coordinators.
  166.  
  167.  
  168. 1.2.8  Top-down Organization.  Checks and Balances.
  169.  
  170. These levels act to distribute the administration and control of FidoNet to
  171. the lowest possible level, while still allowing for coordinated action over
  172. the entire mail system.  Administration is made possible by operating in a
  173. top-down manner.  That is, a person at any given level is responsible to the
  174. level above, and responsible for the level below.
  175.  
  176. For example, a Regional Coordinator is responsible to the Zone Coordinator
  177. for anything that happens in the region.  From the point of view of the Zone
  178. Coordinator, the Regional Coordinator is completely responsible for the
  179. smooth operation of the region.  Likewise, from the point of view of the
  180. Regional Coordinator, the Network Coordinator is completely responsible for
  181. the smooth operation of the network.
  182.  
  183. If a person at any level above sysop is unable to properly perform their
  184. duties, the person at the next level may replace them.  For example, if a
  185. Regional Coordinator fails to perform, the Zone Coordinator can replace him.
  186.  
  187. To provide for checks and balances at the highest level of FidoNet, there are
  188. two exceptions to this top-down organization.  Zone Coordinators and the
  189. International Coordinator are selected by a majority vote of the coordinators
  190. at the level below.  Similarly, decisions made by the International Coordina-
  191. tor can be reversed by the Zone Coordinator Council, and decisions made by a
  192. Zone Coordinator can be reversed by the Regional Coordinators.  See sections
  193. 6 and 7 for details.  Decisions made by other coordinators are not subject to
  194. reversal by a vote of the lower level, but instead are subject to the appeal
  195. process described in section 9.5.
  196.  
  197.  
  198. 1.3  Definitions
  199.  
  200. 1.3.1  FidoNews
  201.  
  202. FidoNews is a weekly newsletter distributed in electronic form throughout the
  203. network.  It is an important medium by which FidoNet sysops communicate with
  204. each other.  FidoNews provides a sense of being a community of people with
  205. common interests.  Accordingly, sysops and users are encouraged to contribute
  206. to FidoNews.  Contributions are submitted to node 1:1/1; a file describing
  207. the format to be used is available from 1:1/1 and many other systems.
  208.  
  209.  
  210. 1.3.2  Geography
  211.  
  212. Each level of FidoNet is geographically contained by the level immediately
  213. above it.  A given geographic location is covered by one zone and one region
  214. within that zone, and is either in one network or not in a network.  There
  215. are never two zones, two regions, or two networks which cover the same
  216. geographic area.
  217.  
  218. If a node is in the area of a network, it should be listed in that network,
  219. not as an independent in the region.  (The primary exception to this is a
  220. node receiving inordinate amounts of host-routed mail; see section 4.2).
  221. Network boundaries are based on calling areas as defined by the local
  222. telephone company.  Even in the case of areas where node density is so great
  223. that more than one network is needed to serve one local calling area, a geo-
  224. graphic guideline is used to decide which nodes belong to what network.
  225. Network membership is based on geographic or other purely technical ratio-
  226. nale.  It is not based on personal or social factors.
  227.  
  228. There are cases in which the local calling areas lead to situations where
  229. logic dictates that a node physically in one FidoNet Region should be
  230. assigned to another.  In those cases, with the agreement of the Regional
  231. Coordinators and Zone Coordinator involved, exemptions may be granted.  Such
  232. exemptions are described in section 5.6.
  233.  
  234. 1.3.3  Zone Mail Hour
  235.  
  236. Zone Mail Hour (ZMH) is a defined time during which all nodes in a zone are
  237. required to be able to accept netmail.  Each Fidonet zone defines a ZMH and
  238. publishes the time of its ZMH to all other Fidonet zones.  See sections 2.1.8
  239. and 10.2.
  240.  
  241. Zone Mail Hour has previously been referred to as National Mail Hour and
  242. Network Mail hour.  The term Zone Mail Hour is more accurate.
  243.  
  244. 1.3.4  Nodelist
  245.  
  246. The nodelist is a file updated weekly which contains the addresses of all
  247. recognized FidoNet nodes.  This file is currently made available by the Zone
  248. Coordinator not later than Zone Mail Hour each Saturday, and is available
  249. electronically for download or file request at no charge.  To be included in
  250. the nodelist, a system must meet the requirements defined by this document.
  251. No other requirements may be imposed.
  252.  
  253. Partial nodelists (single-zone, for example) may be made available at
  254. different levels in FidoNet.  The full list as published by the International
  255. Coordinator is regarded as the official FidoNet nodelist, and is used in
  256. circumstances such as determination of eligibility for voting.  All parts
  257. that make up the full nodelist are available on each Zone Coordinator's and
  258. each Regional Coordinator's system.
  259.  
  260.  
  261. 1.3.5  Excessively Annoying Behavior
  262.  
  263. There are references throughout this policy to "excessively annoying behav-
  264. ior", especially in section 9 (Resolution of Disputes).  It is difficult to
  265. define this term, as it is based upon the judgement of the coordinator
  266. structure.  Generally speaking, annoying behavior irritates, bothers, or
  267. causes harm to some other person.  It is not necessary to break a law to be
  268. annoying.
  269.  
  270. There is a distinction between excessively annoying behavior and (simply)
  271. annoying behavior.  For example, there is a learning curve that each new
  272. sysop must climb, both in the technical issues of how to set up the software
  273. and the social issues of how to interact with FidoNet.  It is a rare sysop
  274. who, at some point in this journey, does not manage to annoy others.  Only
  275. when such behavior persists, after being pointed out to the sysop, does it
  276. becomes excessively annoying.  This does not imply that it is not possible to
  277. be excessively annoying without repetition (for example, deliberate falsifi-
  278. cation of mail would likely be excessively annoying on the very first try),
  279. but simply illustrates that a certain amount of tolerance is extended.
  280.  
  281. Refer to section 9 and the case studies (section 10.3) for more information.
  282.  
  283.  
  284. 1.3.6  Commercial Use
  285.  
  286. FidoNet is an amateur network.  Participants spend their own time and money
  287. to make it work for the good of all the users.  It is not appropriate for a
  288. commercial enterprise to take advantage of these volunteer efforts to further
  289. their own business interests.  On the other  hand, FidoNet provides a
  290. convenient and effective means for companies and users to exchange informa-
  291. tion, to the mutual benefit of all.
  292.  
  293. Network Coordinators could be forced to subsidize commercial operations by
  294. forwarding host-routed netmail, and could even find themselves involved in a
  295. lawsuit if any guarantee was suggested for mail delivery.   It is therefore
  296. FidoNet policy that commercial mail is not to be routed.  "Commercial mail"
  297. includes mail which furthers specific business interests without being of
  298. benefit to the net as a whole.  Examples include company-internal mail,
  299. inter-corporate mail, specific product inquiries (price quotes, for in-
  300. stance), orders and their follow-ups, and  all other subjects specifically
  301. related to business.
  302.  
  303.  
  304. 2  Sysop Procedures
  305.  
  306. 2.1  General
  307.  
  308. 2.1.1  The Basics
  309.  
  310. As the sysop of an individual node, you can generally do as you please, as
  311. long as you observe mail events, are not excessively annoying to other nodes
  312. in FidoNet, and do not promote or participate in the distribution of pirated
  313. copyrighted software or other illegal behavior via FidoNet.
  314.  
  315.  
  316. 2.1.2  Familiarity with Policy
  317.  
  318. In order to understand the meaning of "excessively annoying", it is incumbent
  319. upon all sysops to occasionally re-read FidoNet policy.  New sysops must
  320. familiarize themselves with policy before requesting a node number.
  321.  
  322.  
  323. 2.1.3  Responsible for All Traffic Entering FidoNet Via the Node
  324.  
  325. The sysop listed in the nodelist entry is responsible for all traffic
  326. entering FidoNet via that system.  This includes (but is not limited to)
  327. traffic entered by users, points, and any other networks for which the system
  328. might act as a gateway.  If a sysop allows "outside" messages to enter
  329. FidoNet via the system, the gateway system must be clearly identified by
  330. FidoNet node number as the point of origin of that message, and it must act
  331. as a gateway in the reverse direction.  Should such traffic result in a
  332. violation of Policy, the sysop must rectify the situation.
  333.  
  334.  
  335. 2.1.4  Encryption and Review of Mail
  336.  
  337. FidoNet is an amateur system.  Our technology is such that the privacy of
  338. messages cannot be guaranteed.  As a sysop, you have the right to review
  339. traffic flowing through your system, if for no other reason than to ensure
  340. that the system is not being used for illegal or commercial purposes.
  341. Encryption obviously makes this review impossible.  Therefore, encrypted
  342. and/or commercial traffic that is routed without the express permission of
  343. all the links in the delivery system constitutes annoying behavior.  See
  344. section 1.3.6 for a definition of commercial traffic.
  345.  
  346.  
  347. 2.1.5  No Alteration of Routed Mail
  348.  
  349. You may not modify, other than as required for routing or other technical
  350. purposes, any message, netmail or echomail, passing through the system from
  351. one FidoNet node to another.  If you are offended by the content of a
  352. message, the procedure described in section 2.1.7 must be used.
  353.  
  354.  
  355. 2.1.6  Private Netmail
  356.  
  357. The word "private" should be used with great care, especially with users of a
  358. BBS.  Some countries have laws which deal with "private mail", and it should
  359. be made clear that the word "private" does not imply that no person other
  360. than the recipient can read messages.  Sysops who cannot provide this
  361. distinction should consider not offering users the option of "private mail".
  362.  
  363. If a user sends a "private message", the user has no control over the number
  364. of intermediate systems through which that message is routed.  A sysop who
  365. sends a message to another sysop can control this aspect by sending the
  366. message direct to the recipient's system, thus guaranteeing that only the
  367. recipient or another individual to whom that sysop has given authorization
  368. can read the message.  Thus, a sysop may have different expectations than a
  369. casual user.
  370.  
  371. 2.1.6.1  No Disclosure of in-transit mail
  372.  
  373. Disclosing or in any way using information contained in private netmail
  374. traffic not addressed to you or written by you is considered annoying
  375. behavior, unless the traffic has been released by the author or the recipient
  376. as a part of a formal policy complaint.  This does not apply to echomail
  377. which is by definition a broadcast medium, and where private mail is often
  378. used to keep a sysop-only area restricted.
  379.  
  380. 2.1.6.2  Private mail addressed to you
  381.  
  382. The issue of private mail which is addressed to you is more difficult than
  383. the in-transit question treated in the previous section.  A common legal
  384. opinion holds that when you receive a message it becomes your property and
  385. you have a legal right to do with it what you wish.  Your legal right does
  386. not excuse you from annoying others.
  387.  
  388. In general, sensitive material should not be sent using FidoNet.  This ideal
  389. is often compromised, as FidoNet is our primary mode of communication.  In
  390. general, if the sender of a message specifically requests in the text of the
  391. message that the contents be kept confidential, release of the message into a
  392. public forum may be considered annoying.
  393.  
  394. There are exceptions.  If someone is saying one thing in public and saying
  395. the opposite in private mail, the recipient of the private mail should not be
  396. subjected to harassment simply because the sender requests that the message
  397. not be released.  Judgement and common sense should be used in this area as
  398. in all other aspects of FidoNet behavior.
  399.  
  400. 2.1.7  Not Routing Mail
  401.  
  402. You are not required to route traffic if you have not agreed to do so.  You
  403. are not obligated to route traffic for all if you route it for any, unless
  404. you hold a Network Coordinator or Hub Coordinator position.  Routing traffic
  405. through a node not obligated to perform routing without the permission of
  406. that node may be annoying behavior.  This includes unsolicited echomail.
  407.  
  408. If you do not forward a message when you previously agreed to perform such
  409. routing, the message must be returned to the sysop of the node at which it
  410. entered FidoNet with an explanation of why it was not forwarded.  (It is not
  411. necessary to return messages which are addressed to a node which is not in
  412. the current nodelist.)  Intentionally stopping an in-transit message without
  413. following this procedure constitutes annoying behavior.  In the case of a
  414. failure to forward traffic due to a technical problem, it does not become
  415. annoying unless it persists after being pointed out to the sysop.
  416.  
  417.  
  418. 2.1.8  Exclusivity of Zone Mail Hour
  419.  
  420. Zone Mail Hour is the heart of FidoNet, as this is when network mail is
  421. passed between systems.  Any system which wishes to be a part of FidoNet must
  422. be able to receive mail during this time using the protocol defined in the
  423. current FidoNet Technical Standards Committee publication (FTS-0001 at this
  424. writing).  It is permissible to have greater capability (for example, to
  425. support additional protocols or extended mail hours), but the minimum
  426. requirement is FTS-0001 capability during this one hour of the day.
  427.  
  428. This time is exclusively reserved for netmail.  Many phone systems charge on
  429. a per-call basis, regardless of whether a connect, no connect, or busy signal
  430. is encountered.  For this reason, any activity other than normal network mail
  431. processing that ties up a system during ZMH is considered annoying behavior.
  432. Echomail should not be transferred during ZMH.  User (BBS) access to a system
  433. is prohibited during ZMH.
  434.  
  435. A system which is a member of a local network may also be required to observe
  436. additional mail events, as defined by the Network Coordinator.  Access
  437. restrictions during local network periods are left to the discretion of the
  438. Network Coordinator.
  439.  
  440.  
  441. 2.1.9  Private Nodes
  442.  
  443. The rare exception to ZMH compliance is private nodes.  Persons requesting
  444. private nodes should be supported as points if possible.  A private listing
  445. is justified when the system must interface with many others, such as an
  446. echomail distributor.  In these cases, the exact manner and timing of mail
  447. delivery is arranged between the private node and other systems.  Such an
  448. agreement between a private system and a hub is not binding on any replace-
  449. ment for that hub.  A private node must be a part of a network (they cannot
  450. be independents in the region.)
  451.  
  452. Private listings impact each member of FidoNet, since they take up space in
  453. everyone's nodelist.  Private listings which are for the convenience of one
  454. sysop (at the expense of every other sysop in FidoNet) are a luxury which is
  455. no longer possible.  Non-essential redundant listings (more than one listing
  456. for the same telephone number, except as mandated by FTSC standards) also
  457. fall into this category.  Sysops requesting private or redundant listings
  458. must justify them with a statement explaining how they benefit the local net
  459. or FidoNet as a whole.  The Network Coordinator or Regional Coordinator may
  460. review this statement at any time and listings which are not justified will
  461. be removed.
  462.  
  463.  
  464. 2.1.10  Observing Mail Events
  465.  
  466. Failure to observe the proper mail events is grounds for any node to be
  467. dropped from FidoNet without notice (since notice is generally given by
  468. netmail).
  469.  
  470.  
  471. 2.1.11  Use of Current Nodelist
  472.  
  473. Network mail systems generally operate unattended, and place calls at odd
  474. hours of the night.  If a system tries to call an incorrect or out-of-date
  475. number, it could cause some poor citizen's phone to ring in the wee hours of
  476. the morning, much to the annoyance of innocent bystanders and civil authori-
  477. ties.  For this reason, a sysop who sends mail is obligated to obtain and use
  478. the most recent edition of the nodelist as is practical.
  479.  
  480.  
  481. 2.1.12  Excommunication
  482.  
  483. A system which has been dropped from the network is said to be excommunicated
  484. (i.e. denied communication).  If you find that you have been excommunicated
  485. without warning, your coordinator was unable to contact you.  You should
  486. rectify the problem and contact your coordinator.
  487.  
  488. Systems may also be dropped from the nodelist for cause.  See section 9, and
  489. sections 4.3 and 5.2.
  490.  
  491. It is considered annoying behavior to assist a system which was excommuni-
  492. cated in circumventing that removal from the nodelist.  For example, if you
  493. decide to provide an echomail feed to your friend who has been excommuni-
  494. cated, it is likely that your listing will also be removed.
  495.  
  496.  
  497. 2.1.13  Timing of Zone Mail Hour
  498.  
  499. The exact timing of Zone Mail Hour for each zone is set by the Zone Coordina-
  500. tor.  See section 10.2.
  501.  
  502.  
  503. 2.1.14  Non-observance of Daylight Savings Time
  504.  
  505. FidoNet does not observe daylight savings time.  In areas which observe
  506. daylight savings time the FidoNet mail schedules must be adjusted in the same
  507. direction as the clock change.  Alternatively, you can simply leave your
  508. system on standard time.
  509.  
  510.  
  511. 2.2  How to obtain a node number
  512.  
  513.  
  514. You must first obtain a current nodelist so that you can send mail.  You do
  515. not need a node number to send mail, but you must have one in order for
  516. others to send mail to you.
  517.  
  518. The first step in obtaining a current nodelist is to locate a FidoNet
  519. bulletin board.  Most bulletin board lists include at least a few FidoNet
  520. systems, and usually identify them as such.  Use a local source to obtain
  521. documents because many networks have detailed information available which
  522. explains the coverage area of the network and any special requirements or
  523. procedures.
  524.  
  525. Once you have a nodelist, you must determine which network or region covers
  526. your area.  Regions are numbered 1-99; network numbers are greater than 99.
  527. Networks are more restricted in area than regions, but are preferred since
  528. they improve the flow of mail and provide more services to their members.  If
  529. you cannot find a network which covers your area, then pick the region which
  530. does.
  531.  
  532. Once you have located the network or region in your area, send a message
  533. containing a request for a node number to node zero of that network or
  534. region.  The request must be sent by netmail, as this indicates that your
  535. system has FidoNet capability.
  536.  
  537. You must set up your software so that the from-address in your message does
  538. not cause problems for the coordinator who receives it.  If you pick the
  539. address of an existing system, this will cause obvious problems.  If your
  540. software is capable of using address -1/-1, this is the traditional address
  541. used by potential sysops.  Otherwise use net/9999 (e.g. if you are applying
  542. to net 123, set your system up as 123/9999).  Many nets have specific
  543. instructions available to potential sysops and these procedures may indicate
  544. a preference for the from-address.
  545.  
  546. The message you send must include at least the following information:
  547.  
  548.      1) Your name.
  549.      2) Your voice telephone number
  550.      3) The name of your system.
  551.      4) The city and state where your system is located.
  552.      5) The phone number to be used when calling your system.
  553.      6) Your hours of operation, netmail and BBS.
  554.      7) The maximum baud rate you can support.
  555.      8) The type of mailer software and modem you are using.
  556.  
  557. Your coordinator may contact you for additional information.  All information
  558. submitted will be kept confidential and will not be supplied to anyone except
  559. the person who assumes the coordinator position at the resignation of the
  560. current coordinator.
  561.  
  562. You must indicate that you have read, and agree to abide by, this document
  563. and all the current policies of FidoNet.
  564.  
  565. Please allow at least two weeks for a node number request to be processed.
  566. If you send your request to a Regional Coordinator, it may forwarded to the
  567. appropriate Network Coordinator.
  568.  
  569.  
  570. 2.3  If You are Going Down
  571.  
  572. If your node will be down for an extended period (more than a day or two),
  573. inform your coordinator as soon as possible.  It is not your coordinator's
  574. responsibility to chase you down for a status report, and if your system
  575. stops accepting mail it will be removed from the nodelist.
  576.  
  577. Never put an answering machine or any other device which answers the phone on
  578. your phone line while you are down.  If you do, calling systems will get the
  579. machine repeatedly, racking up large phone bills, which is very annoying.  In
  580. short, the only thing which should ever answer the telephone during periods
  581. when the nodelist indicates that your node will accept mail is FidoNet-
  582. compatible software which accepts mail.
  583.  
  584. If you will be leaving your system unattended for an extended period of time
  585. (such as while you are on vacation), you should notify your coordinator.
  586. Systems have a tendency to "crash" now and then, so you will probably want
  587. your coordinator to know that it is a temporary condition if it happens while
  588. you are away.
  589.  
  590.  
  591. 2.4  How to Form a Network
  592.  
  593. If there are several nodes in your area, but no network, a new network can be
  594. formed.  This has advantages to both you and to the rest of FidoNet.  You
  595. receive better availability of nodelist difference files and FidoNews, and
  596. everyone else can take advantage of host-routing netmail to the new network.
  597.  
  598. The first step is to contact the other sysops in your area.  You must decide
  599. which nodes will comprise the network, and which of those nodes you would
  600. like to be the Network Coordinator.  Then consult your Regional Coordinator.
  601. You must send the following information:
  602.  
  603.    1) The region number(s), or network number(s) if a network is splitting
  604.    up, that are affected by the formation of your network.  The Regional
  605.    Coordinator will inform the Zone Coordinator and the coordinators of any
  606.    affected networks that a new network is in formation.
  607.  
  608.    2) A copy of the proposed network's nodelist segment.  This file should
  609.    be attached to the message of application for a network number, and
  610.    should use the nodelist format described in the current version of the
  611.    appropriate FTSC publication.  Please elect a name that relates to your
  612.    grouping, for example SoCalNet for nodes in the Southern California Area
  613.    and MassNet West for the Western Massachusetts Area.  Remember if you
  614.    call yourself DOGNET it doesn't identify your area.
  615.  
  616. Granting a network number is not automatic.  Even if the request is granted,
  617. the network might not be structured exactly as you request.  Your Regional
  618. Coordinator will review your application and inform you of the decision.
  619.  
  620. Do not send a network number request to the Zone Coordinator.  All network
  621. number requests must be processed by the Regional Coordinator.
  622.  
  623.  
  624.  
  625. 3  General Procedures for All Coordinators
  626.  
  627. 3.1  Make Available Difference Files and FidoNews
  628.  
  629. Any Coordinator is responsible for obtaining and making available, on a
  630. weekly basis, nodelist difference files and FidoNews.
  631.  
  632.  
  633. 3.2  Processing Nodelist Changes and Passing Them Upstream
  634.  
  635. Each coordinator is responsible for obtaining nodelist information from the
  636. level below, processing it, and passing the results to the level above.  The
  637. timing of this process is determined by the requirements imposed by the level
  638. above.
  639.  
  640.  
  641. 3.3  Ensure the Latest Policy is Available
  642.  
  643. A Coordinator is responsible to make the current version of this document
  644. available to the level below, and to encourage familiarity with it.
  645.  
  646. In addition, a coordinator is required to forward any local policies received
  647. to the level above, and to review such policies.  Although not required,
  648. common courtesy dictates that when formulating a local policy, the participa-
  649. tion of the level above should be solicited.
  650.  
  651.  
  652. 3.4  Minimize the Number of Hats Worn
  653.  
  654. Coordinators are encouraged to limit the number of FidoNet functions they
  655. perform.  A coordinator who holds two different positions compromises the
  656. appeal process.  For example, if the Network Coordinator is also the Regional
  657. Coordinator, sysops in that network are denied one level of appeal.
  658.  
  659. Coordinators are discouraged from acting as echomail and software-distri-
  660. bution hubs.  If they do so, they should handle echomail (or other volume
  661. distribution) on a system other than the administrative system.  A coordina-
  662. tor's system should be readily available to the levels immediately above and
  663. below.
  664.  
  665. Another reason to discourage multiple hats is the difficulty of replacing
  666. services if someone leaves the network.  For example, if a coordinator is the
  667. echomail hub and the software-distribution hub, those services will be
  668. difficult to restore when that person resigns.
  669.  
  670. 3.5  Be a Member of the Area Administered
  671.  
  672. A coordinator must be a member of the area administered. That is, a Network
  673. Coordinator must be a member of that network by virtue of geography.  A
  674. Regional Coordinator must be either a member of a network in the region, or
  675. an independent in the region.
  676.  
  677.  
  678. 3.6  Encourage New Sysops to Enter FidoNet
  679.  
  680. A coordinator is encouraged to operate a public bulletin board system which
  681. is freely available for the purpose of distributing Policy, FidoNews, and
  682. Nodelists to potential new sysops.  Dissemination of this information to
  683. persons who are potential FidoNet sysops is important to the growth of
  684. FidoNet, and coordinators should encourage development of new systems.
  685.  
  686.  
  687. 3.7  Tradition and Precedent
  688.  
  689. A coordinator is not bound by the practices of predecessor or peers beyond
  690. the scope of this document.
  691.  
  692. In addition, a new coordinator has the right to review any decision made by
  693. predecessors for compliance with Policy, and take whatever actions may be
  694. necessary to rectify any situations not in compliance.
  695.  
  696.  
  697. 3.8  Technical Management
  698.  
  699. The primary responsibility of any coordinator is technical management of
  700. network operations.  Decisions must be made on technical grounds.
  701.  
  702.  
  703.  
  704. 4  Network Coordinator Procedures
  705.  
  706. 4.1  Responsibilities
  707.  
  708. A Network Coordinator has the following responsibilities:
  709.  
  710.    1) To receive incoming mail for nodes in the network, and arrange
  711.    delivery to its recipients.
  712.  
  713.    2) To assign node numbers to nodes in the network.
  714.  
  715.    3) To maintain the nodelist for the network, and to send a copy of it to
  716.    the Regional Coordinator whenever it changes.
  717.  
  718.    4) To make available to nodes in the network new nodelist difference
  719.    files, new issues of FidoNews, and new revisions of Network Policy
  720.    Documents as they are received, and to periodically check to insure that
  721.    nodes use up to date nodelists.
  722.  
  723.  
  724. 4.2  Routing Inbound Mail
  725.  
  726. It is your responsibility as Network Coordinator to coordinate the receipt
  727. and forwarding of host-routed inbound netmail for nodes in your network.  The
  728. best way to accomplish this is left to your discretion.
  729.  
  730. If a node in your network is receiving large volumes of mail you can request
  731. that the sysop contact the systems which are sending this mail and request
  732. that they not host-route it.  If the problem persists, you can request your
  733. Regional Coordinator to assign the node a number as an independent and drop
  734. the system from your network.
  735.  
  736. Occasionally a node will make a "bombing run" (sending one message to a great
  737. many nodes).  If a node in another network is making bombing runs on your
  738. nodes and routing them through your inbound host, then you can complain to
  739. the network coordinator of the offending node.  (If the node is an indepen-
  740. dent, complain to the regional coordinator.)  Bombing runs are considered to
  741. be annoying.
  742.  
  743. Another source of routing overload is echomail.  Echomail cannot be allowed
  744. to degrade the ability of FidoNet to handle normal message traffic.  If a
  745. node in your network is routing large volumes of echomail, you can ask the
  746. sysop to either limit the amount of echomail or to stop routing echomail.
  747.  
  748. You are not required to forward encrypted, commercial, or illegal mail.
  749. However, you must follow the procedures described in section 2.1.7 if you do
  750. not forward the mail.
  751.  
  752.  
  753. 4.3  Assigning Node Numbers
  754.  
  755. It is your responsibility to assign node numbers to new nodes in your net-
  756. work.  You may also change the numbers of existing nodes in your network,
  757. though you should check with your member nodes before doing so.  You may
  758. assign any numbers you wish, so long as each node has a unique number within
  759. your network.
  760.  
  761. You must not assign a node number to any system until you have received a
  762. formal request from that system by FidoNet mail.  This will ensure that the
  763. system is minimally operational.  The strict maintenance of this policy has
  764. been one of the great strengths of FidoNet.
  765.  
  766. It is also recommended, though not required, that you call a board which is
  767. applying for a node number before assigning it a node number.
  768.  
  769. You may not assign a node number to a node in an area covered by an existing
  770. network.  Further, if you have nodes in an area covered by a network in
  771. formation, those nodes must be transferred to the new network.
  772.  
  773. You should use network mail to inform a new sysop of the node number, as this
  774. helps to insure that the system is capable of receiving network mail.
  775.  
  776. If a node in your network is acting in a sufficiently annoying manner, then
  777. you can take whatever action you deem fit, according to the circumstances of
  778. the case.
  779.  
  780.  
  781. 4.4  Maintaining the Nodelist
  782.  
  783.  
  784. You should implement name changes, phone number changes, and so forth in your
  785. segment of the nodelist as soon as possible after the information is received
  786. from the affected node.  You should also on occasion send a message to every
  787. node in your network to ensure that they are operational.  If a node turns
  788. out to be "off the air" with no prior warning, you can either mark the node
  789. down or remove it from the nodelist.  (Nodes are to be marked DOWN for a
  790. maximum of two weeks, after which the line should be removed from the node-
  791. list.)
  792.  
  793. At your discretion, you may distribute a portion of this workload to routing
  794. hubs.  In this case, you should receive the nodelists from the Hub Coordina-
  795. tors within your network.  You will need to maintain a set of nodelists for
  796. each hub within your network, since you cannot count on getting an update
  797. from each Hub Coordinator every week.  You should assemble a master nodelist
  798. for your network every week and send it to your Regional Coordinator by the
  799. day and time designated.  It is suggested that you do this as late as is
  800. practical, so as to accommodate any late changes, balanced with the risk of
  801. missing the connection with your Regional Coordinator and thus losing a week.
  802.  
  803. 4.5  Making Available Policies, Nodelists and FidoNews
  804.  
  805. As a Network Coordinator you should obtain a new issue of FidoNews and a new
  806. nodelist difference file every week from your Regional Coordinator.  The
  807. nodelist difference file is currently made available each Saturday, and
  808. FidoNews is published each Monday.  You must make these files available to
  809. all nodes in the network, and you are encouraged to make them available to
  810. the general public for download.
  811.  
  812. You should also obtain the most recent versions of the Policy documents that
  813. bind the members of your network, and make those available to the nodes in
  814. your network.  Policies are released at sporadic intervals, so you should
  815. also inform the nodes in your network when such events occur, and ensure the
  816. nodes are generally familiar with the changes.
  817.  
  818. Policy, FidoNews, and the nodelist are the glue that holds us together.
  819. Without them, we would cease to be a community, and become just another
  820. random collection of bulletin boards.
  821.  
  822.  
  823.  
  824. 5  Regional Coordinator Procedures
  825.  
  826. 5.1  Responsibilities
  827.  
  828. A Regional Coordinator has the following responsibilities:
  829.  
  830.    1) To assign node numbers to independent nodes in the region.
  831.  
  832.    2) To encourage independent nodes in the region to join existing net-
  833.    works, or to form new networks.
  834.  
  835.    3) To assign network numbers to networks in the region and define their
  836.    boundaries.
  837.  
  838.    4) To compile a nodelist of all of the networks and independents in the
  839.    region, and to send a copy of it to the Zone Coordinator whenever it
  840.    changes.
  841.  
  842.    5) To ensure the smooth operation of networks within the region.
  843.  
  844.    6) To make new nodelist difference files, Policies, and issues of
  845.    FidoNews available to the Network Coordinators in the region as soon as
  846.    is practical.
  847.  
  848.  
  849. 5.2  Assigning Node Numbers
  850.  
  851. It is your responsibility to assign node numbers to independent nodes in your
  852. region. You may also change the numbers of existing nodes in your region,
  853. though you should check with the respective nodes before doing so.  You may
  854. assign any numbers you wish, so long as each node has a unique number within
  855. your region.
  856.  
  857. You should not assign a node number to any system until you have received a
  858. formal request from that system by FidoNet mail.  This will ensure that the
  859. system is minimally operational.  The strict maintenance of this policy has
  860. been one of the great strengths of FidoNet.
  861.  
  862. It is also recommended, though not required, that you call a board which is
  863. applying for a node number before assigning it a node number.
  864.  
  865. You should use network mail to inform a new sysop of the node number, as this
  866. helps to insure that the system is capable of receiving network mail.
  867.  
  868. If a node in your region is acting in a sufficiently annoying manner, then
  869. you can take whatever action you deem fit, according to the circumstances of
  870. the case.
  871.  
  872. If you receive a node number request from outside your region, you must
  873. forward it to the most local coordinator for the requestor as you can deter-
  874. mine.  If you receive a node number request from a new node that is in an
  875. area covered by an existing network, then you must forward the request to the
  876. Coordinator of that network instead of assigning a number yourself.
  877.  
  878. If a network forms in an area for which you have independent nodes, those
  879. nodes will be transferred to the local network as soon as is practical.
  880.  
  881.  
  882. 5.3  Encouraging the Formation and Growth of Networks
  883.  
  884. One of your main duties as a Regional Coordinator is to promote the growth of
  885. networks in your region.
  886.  
  887. You should avoid having independent nodes in your region which are within the
  888. coverage area of a network.  There are, however, certain cases where a node
  889. should not be a member of a network, such as a system with a large amount of
  890. inbound netmail; see section 4.2.
  891.  
  892. If several independent nodes in your region are in a local area you should
  893. encourage them to form a network, and if necessary you may require them to
  894. form a network.  Refer to section 2.4.  Note that this is not intended to
  895. encourage the formation of trivial networks.  Obviously, one node does not
  896. make a network.  The exact number of nodes required for an effective network
  897. must be judged according to the circumstances of the situation, and is left
  898. to your discretion.
  899.  
  900.  
  901. 5.4  Assigning Network Numbers
  902.  
  903. It is your responsibility to assign network numbers to new networks forming
  904. within your region.  You are assigned a pool of network numbers to use for
  905. this purpose by your Zone Coordinator.  As a part of this function, it is the
  906. responsibility of the Regional Coordinator to define the boundaries of the
  907. networks in the region.
  908.  
  909.  
  910. 5.5  Maintaining the Nodelist
  911.  
  912. As a Regional Coordinator, you have a dual role in maintaining the nodelist
  913. for your region.
  914.  
  915. First, you must maintain the list of independent nodes in your region.  You
  916. should attempt to implement name changes, phone number changes, and so forth
  917. in this nodelist as soon as possible.  You should also on occasion send a
  918. message to every independent node in your region to ensure that they are
  919. operational.  If a node turns out to be "off the air" with no prior warning,
  920. you can either mark the node down or remove it from the nodelist.  (Nodes are
  921. to marked DOWN for a maximum of two weeks, after which the line should be
  922. removed from the nodelist.)
  923.  
  924. Second, you must receive the nodelists from the Network Coordinators within
  925. your region.  You will need to maintain a set of nodelists for each network
  926. within your region, since you cannot count on getting an update from each
  927. Network Coordinator every week.  You should assemble a master nodelist for
  928. your region every week and send it to your Zone Coordinator by the day and
  929. time designated.  It is suggested that you do this as late as practical, so
  930. as to accommodate late changes, balanced with the risk of missing the connec-
  931. tion with your Zone Coordinator and thus losing a week.
  932.  
  933.  
  934. 5.6  Geographic Exemptions
  935.  
  936. There are cases where local calling geography does not follow FidoNet re-
  937. gions.  In exceptional cases, exemptions to normal geographic guidelines are
  938. agreed upon by the Regional Coordinators and Zone Coordinator involved.  Such
  939. an exemption is not a right, and is not permanent.  When a network is formed
  940. in the proper region that would provide local calling access to the exempted
  941. node, it is no longer exempt.  An exemption may be reviewed and revoked at
  942. any time by any of the coordinators involved.
  943.  
  944.  
  945. 5.7  Overseeing Network Operations
  946.  
  947. You are responsible for appointing network coordinators for the nets in your
  948. region.  If the outgoing Network Coordinator suggests a successor, you are
  949. not obligated to accept that individual, although you normally will.  Simi-
  950. larly, you are not obligated to accept the individual selected by the members
  951. of the network in an election, although you normally will.
  952.  
  953. It is your responsibility as Regional Coordinator to ensure that the networks
  954. within your region are operating in an acceptable manner.  This does not mean
  955. that you are required to operate those networks; that is the responsibility
  956. of the Network Coordinators.  It means that you are responsible for assuring
  957. that the Network Coordinators within your region are acting responsibly.
  958.  
  959. If you find that a Network Coordinator within your region is not properly
  960. performing the duties outlined in Section 4, you should take whatever action
  961. you deem necessary to correct the situation.
  962.  
  963. If a network grows so large that it cannot reasonably accommodate traffic
  964. flow during the Zone Mail Hour, the Regional Coordinator can direct the
  965. creation of one or more new networks from that network.  These new networks,
  966. although they may be within a single local-calling area, must still conform
  967. to a geographical basis for determining membership.
  968.  
  969. It is your obligation as Regional Coordinator to maintain direct and reason-
  970. ably frequent contact with the networks in your region. The exact method of
  971. accomplishing this is left to your discretion.
  972.  
  973.  
  974. 5.8  Making Available Nodelists, Policies, and FidoNews
  975.  
  976. As a Regional Coordinator, it is your responsibility to obtain the latest
  977. nodelist difference file, network policies, and the latest issues of FidoNews
  978. as they are published, and to make them available to the Network Coordinators
  979. within your region.  The nodelist is posted weekly on Saturday by the Zone
  980. Coordinator, and FidoNews is published weekly on Monday by node 1/1.  Contact
  981. them for more details on how to obtain the latest copies each week.
  982.  
  983. It is your responsibility to make these available to all Network  Coordina-
  984. tors in your region as soon as is practical after you receive them.  The
  985. method of distribution is left to your discretion.  You are not required to
  986. distribute them to any independent nodes in your region, though you may if
  987. you wish.  You are encouraged to make all these documents available for
  988. downloading by the general public.
  989.  
  990.  
  991.  
  992. 6  Zone Coordinator Procedures
  993.  
  994. 6.1  General
  995.  
  996. A Zone Coordinator for FidoNet has the primary task of maintaining the
  997. nodelist for the Zone, sharing it with the other Zone Coordinators, and
  998. ensuring the distribution of the master nodelist (or difference file) to the
  999. Regions in the Zone.  The Zone Coordinator is also responsible for coordinat-
  1000. ing the distribution of Network Policy documents and FidoNews to the Regional
  1001. Coordinators in the zone.
  1002.  
  1003. The Zone Coordinator is responsible for the maintenance of the nodelist for
  1004. the administrative region.  The Administrative Region has the same number as
  1005. the zone, and consists of nodes assigned for administrative purposes not
  1006. related to the sending and receiving of normal network mail.
  1007.  
  1008. A Zone Coordinator is charged with the task of ensuring the smooth operation
  1009. of the Zone, which is done by appointing and supervising the Regional Coordi-
  1010. nators.
  1011.  
  1012. If a Zone Coordinator determines that a Regional Coordinator is not properly
  1013. performing the duties outlined in section 5, a replacement should be found.
  1014.  
  1015. The Zone Coordinator defines the geographic boundaries of the regions within
  1016. the zone and sets the time for the Zone Mail Hour.
  1017.  
  1018. The Zone Coordinator is responsible for reviewing and approving any geograph-
  1019. ic exemptions as described in section 5.6.
  1020.  
  1021. The Zone Coordinator is responsible for insuring the smooth operation of
  1022. gates between that zone and all other zones for the transfer of interzonal
  1023. mail.
  1024.  
  1025. The Zone Coordinators are responsible for the selection of the International
  1026. Coordinator from among their ranks.
  1027.  
  1028.  
  1029. 6.2  Selection
  1030.  
  1031. The Zone Coordinator is selected by an absolute majority vote of the Regional
  1032. Coordinators within the zone.
  1033.  
  1034.  
  1035. 7  International Coordinator Procedures
  1036.  
  1037. 7.1  General
  1038.  
  1039. The International Coordinator is the "first among equals" Zone Coordinator.
  1040.  
  1041. The International Coordinator has the primary task of coordinating the
  1042. creation of the master nodelist by managing the distribution between the
  1043. Zones of the Zone nodelists.  The International Coordinator is responsible
  1044. for definition of new zones and for negotiation of agreements for communica-
  1045. tion with other networks.  ("Other network" in this context means other
  1046. networks with which FidoNet communicates as peer-to-peer, not "network" in
  1047. the sense of the FidoNet organizational level.)
  1048.  
  1049. The International Coordinator is also responsible for coordinating the
  1050. distribution of Network Policies and FidoNews to the Zone Coordinators.
  1051.  
  1052. The International Coordinator is responsible for coordinating the activities
  1053. of the Zone Coordinator Council.  The International Coordinator acts as the
  1054. spokesman for the Zone Coordinator Council.
  1055.  
  1056. In cases not specifically covered by this document, the International Coordi-
  1057. nator may issue specific interpretations or extensions to this policy.  The
  1058. Zone Coordinator Council may reverse such rulings by a majority vote.
  1059.  
  1060. 7.2  Selection
  1061.  
  1062. The International Coordinator is selected (or removed) by an absolute majori-
  1063. ty vote of the Zone Coordinators.
  1064.  
  1065.  
  1066. 8  Referenda
  1067.  
  1068. The procedures described in this section are used to ratify a new version of
  1069. FidoNet policy, which is the mechanism by which policy is changed.  This
  1070. procedure is also used to impeach a Zone Coordinator.
  1071.  
  1072.  
  1073. 8.1  Initiation
  1074.  
  1075. A referendum on policy modification is invoked when a majority  of the
  1076. FidoNet Regional Coordinators inform the International Coordinator that they
  1077. wish to consider a proposed new version of Policy.
  1078.  
  1079.  
  1080. 8.2  Announcement and Results Notification
  1081.  
  1082. Proposed changes to Policy are distributed using the same structure which is
  1083. used to distribute nodelist difference files and FidoNews.  Results and
  1084. announcements related to the referendum are distributed by the coordinator
  1085. structure as a part of the weekly nodelist difference file.  The Interna-
  1086. tional Coordinator provides copies to the editor of FidoNews for inclusion
  1087. there, although the official announcement and voting dates are tied to
  1088. nodelist distributions.
  1089.  
  1090. If it is adopted, the International Coordinator sets the effective date for a
  1091. new policy through announcement in the weekly nodelist difference file.  The
  1092. effective date will be not more than one month after the close of balloting.
  1093.  
  1094.  
  1095. 8.3  Eligibility to Vote
  1096.  
  1097. Each member of the FidoNet coordinator structure at and above Network Coordi-
  1098. nator is entitled to one vote.  (Hub coordinators do not vote.)  In the case
  1099. of the position changing hands during the balloting process, either the
  1100. incumbent or the new coordinator may vote, but not both.  If a person holds
  1101. more than one coordinator position, they still receive only one vote.
  1102.  
  1103. Network coordinators are expected to assess the opinions of the members of
  1104. their network, and to vote accordingly.  A formal election is not necessary,
  1105. but the network coordinator must inform the net of the issues and solicit
  1106. input.  The network coordinator functions as the representative of the rank
  1107. and file members of FidoNet.
  1108.  
  1109.  
  1110. 8.4  Voting Mechanism
  1111.  
  1112. The actual voting mechanism, including whether the ballot is secret and how
  1113. the ballots are to be collected, verified, and counted, is left to the
  1114. discretion of the International Coordinator.  Ideally, ballot collection
  1115. should be by some secure message system, conducted over FidoNet itself.
  1116.  
  1117. In order to provide a discussion period, the announcement of any ballot must
  1118. be made at least two weeks before the date of voting commencement.  The
  1119. balloting period must be at least two weeks.
  1120.  
  1121.  
  1122. 8.5  Voting on a whole Policy Document
  1123.  
  1124. Given that Policy is intertwined and self referencing, a relatively simple
  1125. change may require several alterations of the document.  In order to simplify
  1126. the process, balloting is done on choices between whole documents, rather
  1127. than individual amendments.  In the simplest case, this means voting yea or
  1128. nay to a new document.  If a number of alternatives are to be considered,
  1129. they must be presented as whole documents, from which one is chosen.
  1130.  
  1131.  
  1132. 8.6  Decision of vote
  1133.  
  1134. A Policy amendment is considered in force if, at the end of the balloting
  1135. period, it has received a majority of the votes cast.  For example, if there
  1136. were 350 eligible voters, 100 of which cast a vote, then at least 51 affirma-
  1137. tive votes would be required to declare the amendment in force.
  1138.  
  1139. In the case of multiple policy changes which are considered on the same
  1140. ballot, a version must receive more than 50% of the votes cast to be consid-
  1141. ered ratified.  "Abstain" is a valid vote in this case, effectively being a
  1142. vote for not changing the current policy as it simply increases the number of
  1143. votes required to ratify the proposed change.
  1144.  
  1145.  
  1146. 8.7  Impeachment of a Zone Coordinator
  1147.  
  1148. 8.7.1  Initiation
  1149.  
  1150. In extreme cases, a Zone Coordinator may be impeached by referendum.  Im-
  1151. peachment of a Zone Coordinator does not require a Policy violation.  An
  1152. impeachment proceeding is invoked when a majority of the Regional Coordina-
  1153. tors in a zone request the International Coordinator to institute it.
  1154.  
  1155. 8.7.2  Procedure as in Policy Referendum
  1156.  
  1157. The provisions of sections 8.2 and 8.3 apply to impeachment referenda.
  1158.  
  1159. The definition of "majority" in section 8.6 applies.  Only coordinators in
  1160. the affected zone vote (even if the zone coordinator is also the Internation-
  1161. al Coordinator).
  1162.  
  1163. 8.7.3  Voting Mechanism
  1164.  
  1165. The balloting procedures are set, the votes are collected, and the results
  1166. are announced by a Regional Coordinator chosen by the Zone Coordinator who is
  1167. being impeached.  The removal of the Zone Coordinator is effective two weeks
  1168. after the end of balloting if the impeachment carries.
  1169.  
  1170. 8.7.4  Limited to once per year
  1171.  
  1172. The removal of a Zone Coordinator is primarily intended to be a mechanism by
  1173. which the net as a whole expresses displeasure with the way Policy is being
  1174. interpreted.  At one time or another, everyone is unhappy with the way policy
  1175. is interpreted.  In order to keep the Zone Coordinators interpreting policy
  1176. as opposed to defending themselves, at least one full calendar year must
  1177. elapse between impeachment referenda (regardless of how many people hold the
  1178. position of Zone Coordinator during that year.)
  1179.  
  1180. Should a Zone Coordinator resign during an impeachment process, the process
  1181. is considered null and void, and does not consume the "once per year quota".
  1182.  
  1183.  
  1184. 9  Resolution of Disputes
  1185.  
  1186. 9.1  General
  1187.  
  1188. The FidoNet judicial philosophy can be summed up in two rules:
  1189.  
  1190.      1) Thou shalt not excessively annoy others.
  1191.  
  1192.      2) Thou shalt not be too easily annoyed.
  1193.  
  1194. In other words, there are no hard and fast rules of conduct, but reasonably
  1195. polite behavior is expected.  Also, in any dispute both sides are examined,
  1196. and action could be taken against either or both parties. ("Judge not, lest
  1197. ye be judged!")
  1198.  
  1199. The coordinator structure has the responsibility for defining "excessively
  1200. annoying".  Like a common definition of pornography ("I can't define it, but
  1201. I know it when I see it."), a hard and fast definition of acceptable FidoNet
  1202. behavior is not possible.  The guidelines in this policy are deliberately
  1203. vague to provide the freedom that the coordinator structure requires to
  1204. respond to the needs of a growing and changing community.
  1205.  
  1206. The first step in any dispute between sysops is for the sysops to attempt to
  1207. communicate directly, at least by netmail, preferably by voice.  Any com-
  1208. plaint made that has skipped this most basic communication step will be
  1209. rejected.
  1210.  
  1211. Filing a formal complaint is not an action which should be taken lightly.
  1212. Investigation and response to complaints requires time which coordinators
  1213. would prefer to spend doing more constructive activities.  Persons who
  1214. persist in filing trivial policy complaints may find themselves on the wrong
  1215. side of an excessively-annoying complaint.  Complaints must be accompanied
  1216. with verifiable evidence, generally copies of messages; a simple word-of-
  1217. mouth complaint will be dismissed out of hand.
  1218.  
  1219. Failure to follow the procedures herein described (in particular, by skipping
  1220. a coordinator, or involving a coordinator not in the appeal chain) is in and
  1221. of itself annoying behavior.
  1222.  
  1223.  
  1224. 9.2  Problems with Another Sysop
  1225.  
  1226. If you are having problems with another sysop, you should first try to work
  1227. it out via netmail or voice conversation with the other sysop.
  1228.  
  1229. If this fails to resolve the problem, you should complain to your Network
  1230. Coordinator and the other sysop's Network Coordinator.  If one or both of you
  1231. is not in a network, then complain to the appropriate Regional Coordinator.
  1232. Should this fail to provide satisfaction, you have the right to follow the
  1233. appeal process described in section 9.5.
  1234.  
  1235.  
  1236. 9.3  Problems with your Network Coordinator
  1237.  
  1238. If you are having problems with your Network Coordinator and feel that you
  1239. are not being treated properly, you are entitled to a review of your situa-
  1240. tion.  As with all disputes, the first step is to communicate directly to
  1241. attempt to resolve the problem.
  1242.  
  1243. The next step is to contact your Regional Coordinator.  If your case has
  1244. merit, there are several possible courses of action, including a change of
  1245. Network Coordinators or even the disbanding of your network.  If you have
  1246. been excommunicated by your Network Coordinator, that judgement may be
  1247. reversed, at which point you will be reinstated into your net.
  1248.  
  1249. If you fail to obtain relief from your Regional Coordinator, you have the
  1250. right to follow the appeal process described in section 9.5.
  1251.  
  1252.  
  1253. 9.4  Problems with Other Coordinators
  1254.  
  1255. Complaints concerning annoying behavior on the part of any coordinator are
  1256. treated as in section 9.2 and should be filed with the next level of coordi-
  1257. nator.  For example, if you feel that your Regional Coordinator is guilty of
  1258. annoying behavior (as opposed to a failure to perform duties as a coordina-
  1259. tor) you should file your complaint with the Zone Coordinator.
  1260.  
  1261. Complaints concerning the performance of a coordinator in carrying out the
  1262. duties mandated by policy are accepted only from the level immediately below.
  1263. For example, complaints concerning the performance of Regional Coordinators
  1264. would be accepted from Network Coordinators and independents in that region.
  1265. Such complaints should be addressed to the Zone Coordinator after an appro-
  1266. priate attempt to work them out by direct communications.
  1267.  
  1268.  
  1269. 9.5  Appeal Process
  1270.  
  1271. A decision made by a coordinator may be appealed to the next level.  Appeals
  1272. must be made within two weeks of the decision which is being appealed.  All
  1273. appeals must follow the chain of command; if levels are skipped the appeal
  1274. will be dismissed out of hand.
  1275.  
  1276. An appeal will not result in a full investigation, but will be based upon the
  1277. documentation supplied by the parties at the lower level.  For example, an
  1278. appeal of a Network Coordinator's decision will be decided by the Regional
  1279. Coordinator based upon information provided by the coordinator and the sysop
  1280. involved; the Regional Coordinator is not expected to make an independent
  1281. attempt to gather information.
  1282.  
  1283. The appeal structure is as follows:
  1284.  
  1285.    Network Coordinator decisions may be appealed to the appropriate Region-
  1286.    al Coordinator.
  1287.  
  1288.    Regional Coordinator decisions may be appealed to the appropriate Zone
  1289.    Coordinator.  At this point, the Zone Coordinator will make a decision
  1290.    and communicate it to the Regional Coordinators in that zone.  This
  1291.    decision may be reversed by a majority vote of the Regional Coordina-
  1292.    tors.
  1293.  
  1294.    Zone Coordinator decisions may be appealed to the International Coordi-
  1295.    nator.  The International Coordinator will make a decision and communi-
  1296.    cate it to the Zone Coordinator Council, which may reverse it by majori-
  1297.    ty vote.
  1298.  
  1299. If your problem is with a Zone Coordinator per se, that is, a Zone Coordina-
  1300. tor has committed a Policy violation against you, your complaint should be
  1301. filed with the International Coordinator, who will make a decision and submit
  1302. it to the Zone Coordinator Council for possible reversal, as described above.
  1303.  
  1304.  
  1305. 9.6  Statute of Limitations
  1306.  
  1307. A complaint may not be filed more than 60 days after the date of discovery of
  1308. the source of the infraction, either by admission or technical evidence.
  1309. Complaints may not be filed more than 120 days after the incident unless they
  1310. involve explicitly illegal behavior.
  1311.  
  1312.  
  1313. 9.7  Right to a Speedy Decision
  1314.  
  1315. A coordinator is required to render a final decision and notify the parties
  1316. involved within 30 days of the receipt of the complaint or appeal.
  1317.  
  1318.  
  1319. 9.8  Return to Original Network
  1320.  
  1321. Once a policy dispute is resolved, any nodes reinstated on appeal are re-
  1322. turned to the local network or region to which they geographically or techni-
  1323. cally belong.
  1324.  
  1325.  
  1326. 9.9  Echomail
  1327.  
  1328. Echomail is an important and powerful force in FidoNet.  For the purposes of
  1329. Policy Disputes, echomail is simply a different flavor of netmail, and is
  1330. therefore covered by Policy.  By its nature, echomail places unique technical
  1331. and social demands on the net over and above those covered by this version of
  1332. Policy.  In recognition of this, an echomail policy which extends (and does
  1333. not contradict) general Policy, maintained by the Echomail Coordinators, and
  1334. ratified by a process similar to that of this document, is recognized by the
  1335. FidoNet Coordinators as a valid structure for dispute resolution on matters
  1336. pertaining to echomail.  At some future date the echomail policy document may
  1337. be merged with this one.
  1338.  
  1339.  
  1340. 9.10  Case Histories
  1341.  
  1342. Most of FidoNet Policy is interpretive in nature.  No one can see what is to
  1343. come in our rapidly changing environment.  Policy itself is only a part of
  1344. what is used as the ground rules for mediating disputes -- as or more impor-
  1345. tant are the precedents.
  1346.  
  1347. In order to accommodate this process, case histories may be added to or
  1348. removed from this document by the International Coordinator, with such a
  1349. revision subject to reversal by the Zone Coordinator Council.  Should Policy
  1350. be amended in such a way to invalidate a precedent, Policy supersedes said
  1351. precedent.  (A carefully prepared amendment would address this by removing
  1352. the precedent reference as a part of the amendment.)
  1353.  
  1354. Although a case may be removed, the text of a case history may not be modi-
  1355. fied by any mechanism.  Case history is written close to the time of the
  1356. decision, by those involved with it.  Amending the text of a case history is
  1357. the same as revising history, something quite inappropriate in an organiza-
  1358. tion dedicated to moving information.
  1359.  
  1360.  
  1361.  
  1362. 10  Appendices
  1363.  
  1364. 10.1  General
  1365.  
  1366. The Appendices of this document are exceptions to the normal ratification
  1367. process.  Section 10.2 can be changed by the appropriate Zone Coordinator,
  1368. and section 10.3 may be modified by the International Coordinator (see
  1369. Section 9.10).
  1370.  
  1371.  
  1372. 10.2  Timing of Zone Mail Hour
  1373.  
  1374. Zone Mail Hour is observed each day, including weekends and holidays.  The
  1375. time is based upon Universal Coordinated Time (UTC), also known as Greenwich
  1376. Mean time (GMT).  In areas which observe Daylight Savings Time during part of
  1377. the year, the local time of zone mail hour will change because FidoNet does
  1378. not observe Daylight Savings Time. The exact timing of Zone Mail Hour is set
  1379. for each zone by the Zone Coordinator.
  1380.  
  1381. In FidoNet Zone 1, Zone Mail Hour is observed from 0900 to 1000 UTC.  In each
  1382. of the time zones, this is:
  1383.  
  1384.      Eastern Standard Time          4 AM to 5 AM
  1385.      Central Standard Time          3 AM to 4 AM
  1386.      Mountain Standard Time          2 AM to 3 AM
  1387.      Pacific Standard Time          1 AM to 2 AM
  1388.      Hawaii Standard Time          11 PM to Midnight
  1389.  
  1390. In FidoNet Zone 2, Zone Mail Hour is observed from 0230 to 0330 UTC.
  1391.  
  1392. In Fidonet Zone 3, Zone Mail Hour is observed from 1800 to 1900 UTC.  In each
  1393. of the time Zones involved this is:
  1394.  
  1395.  
  1396.   GMT +12 Zone                        6:00 AM to 7:00 AM
  1397.   (New Zealand)
  1398.  
  1399.   GMT +10 Zone                        4:00 AM to 5:00 AM
  1400.   (East Australia)
  1401.   (Papua New Guinea)
  1402.   (Micronesia)
  1403.  
  1404.   GMT +9.5 Zone                       3:30 AM to 4:30 AM
  1405.   (Central Australia)
  1406.  
  1407.   GMT +9 Zone                         3:00 AM to 4:00 AM
  1408.   (Japan)
  1409.   (Korea)
  1410.   (Eastern Indonesia)
  1411.  
  1412.   GMT +8 Zone                         2:00 AM to 3:00 AM
  1413.   (Hong Kong)
  1414.   (Taiwan)
  1415.   (Central Indonesia)
  1416.   (Philippines)
  1417.   (Western Australia)
  1418.  
  1419.   GMT +7 Zone                         1:00 AM to 2:00 AM
  1420.   (Malaysia)
  1421.   (Singapore)
  1422.   (Thailand)
  1423.   (Western Indonesia)
  1424.  
  1425.  
  1426. 10.3  Case Histories
  1427.  
  1428.  
  1429. Case histories of past disputes are instructive to show general procedures
  1430. and methods.  Any decision may be included in this document by a majority
  1431. vote of either the Zone Coordinator Council or the Regional Coordinators.
  1432.  
  1433. Policy4 significantly changes the functions of the Zone and International
  1434. Coordinators.  In the following cases which were decided using Policy3,
  1435. substitute "Zone Coordinator" for all occurrences of "International Coordina-
  1436. tor(*)".
  1437.  
  1438.  
  1439. 10.3.1  The Case of the Crooked Node
  1440.  
  1441. A sysop of a local node was using network mail to engage in unethical busi-
  1442. ness practices.  The Network Coordinator became very annoyed at this, and
  1443. dropped the local from the nodelist.
  1444.  
  1445. The local appealed to the Regional Coordinator for assignment as an indepen-
  1446. dent node.  The Regional Coordinator, after checking with the Network Coordi-
  1447. nator, decided that the Network Coordinator was right to be annoyed.  Inde-
  1448. pendent status was denied.
  1449.  
  1450. The International Coordinator(*) did not intervene.
  1451.  
  1452.  
  1453. 10.3.2  The Case of the Hacker Mailer
  1454.  
  1455. A sysop of a local node made use of file attaches for extra users to mail
  1456. himself the USER.BBS file from several local boards.  The sysops of these
  1457. boards felt annoyed at this, and appealed to their Network Coordinator, who
  1458. agreed and dropped the offending node from the nodelist.
  1459.  
  1460. The Regional Coordinator was not consulted.
  1461.  
  1462. The International Coordinator(*) did not intervene.
  1463.  
  1464.  
  1465. 10.3.3  The Case of the Bothered Barker
  1466.  
  1467. A local node became annoyed with the Network Coordinator for failing to
  1468. provide services.  Repeated complaints to the Network Coordinator did not
  1469. satisfy him, so he appealed to the International Coordinator(*).
  1470.  
  1471. The International Coordinator(*) dismissed the complaint because the Regional
  1472. Coordinator had not been consulted.
  1473.  
  1474. The local node submitted the complaint to his Regional Coordinator, who
  1475. investigated the case and discovered that there was some justice to the
  1476. complaint.  He advised and assisted the Network Coordinator in configuring
  1477. his system to provide an improved level of service to the local nodes.
  1478.  
  1479. The Regional Coordinator also decided that the local node was being too
  1480. easily annoyed, in that he was expecting services not normally required of a
  1481. Network Coordinator.  The local node was informed as to the true duties of a
  1482. Network Coordinator, and was advised to lower his expectations.
  1483.  
  1484.  
  1485. 10.3.4  The Case of the Busy Beaver
  1486.  
  1487. A local node which was operated by a retail establishment was engaged in
  1488. making "bombing runs" to mail advertisements over FidoNet.  The Network
  1489. Coordinator felt annoyed and handling the outgoing traffic for a commercial
  1490. operation, and asked the local node to leave the network.
  1491.  
  1492. The local node applied to the Regional Coordinator, and was granted status as
  1493. an independent node in the region.
  1494.  
  1495.  
  1496. 10.3.5  The Mark of the Devil
  1497.  
  1498. A local sysop whose board was used in conjunction with voodoo rites, hacking,
  1499. phreaking, and obscene material applied to a Network Coordinator for a node
  1500. number.  The Network Coordinator deemed that this board was exceptionally
  1501. annoying, and denied the request.
  1502.  
  1503. The Regional Coordinator was not consulted.
  1504.  
  1505. The International Coordinator(*), on seeing that the Regional Coordinator had
  1506. not been consulted, dismissed the case out of hand.  No further appeals were
  1507. made.
  1508.  
  1509.  
  1510. 10.3.6  The Case of the Sysop Twit
  1511.  
  1512. A patron of various local nodes had been roundly recognized by all sysops as
  1513. a twit.  The user obtained his own system, became a sysop, and applied for a
  1514. node number.  The Network Coordinator denied the request.  No appeals were
  1515. made.
  1516.  
  1517.  
  1518. 10.3.7  The Case of the Echomail Junkie
  1519.  
  1520. A local node became enamored with echomail and joined several conferences,
  1521. routing mail through his network.  He then started an echomail conference of
  1522. his own and began relaying echomail between several systems, again routing it
  1523. all through the network.
  1524.  
  1525. His Network Coordinator observed that network performance was becoming
  1526. seriously impaired.  The offending node was told to hold it down.  A compro-
  1527. mise was reached whereby much of the echomail traffic was no longer routed
  1528. through the network, and routed echomail was limited to twenty messages per
  1529. night.  No appeals were made.
  1530.  
  1531.  
  1532. 10.3.8  The Case of the Bouncing Board
  1533.  
  1534. A local user decided to establish a node to promote a worthy charity.  The
  1535. machine being used was also used for various other activities during the day,
  1536. and the sysop was often called away.  His coworkers would often forget to
  1537. bring the board up at the end of the day while he was away, so the node was
  1538. often down for extended periods.  The Network Coordinator, finding the node
  1539. unable to receive mail, would mark it down.  The sysop would return, restart
  1540. the board, and ask to be reinstated.
  1541.  
  1542. The Network Coordinator eventually decided that the sysop was not able to
  1543. maintain a reliable system, and removed him from the nodelist completely.
  1544. Subsequent requests for a node number from the same sysop were turned down.
  1545. No appeals were made.
  1546.  
  1547.  
  1548. 10.5  Credits, acknowledgments, etc.
  1549.  
  1550. Fido and FidoNet are registered trademarks of Fido Software, Inc.
  1551.  
  1552.  
  1553.  
  1554.  
  1555.                                      Index
  1556.  
  1557. -1/-1,  2.3
  1558. Additional mail events in local network  2.1.8
  1559. Address in message to request node  2.2
  1560. Administrative Region  6.1
  1561. Advantages to network membership  2.2
  1562. Alteration of mail  2.1.5
  1563. Answering machine  2.3
  1564. Announcement of voting results 8.2
  1565. Annoying behavior  1.3.5, 1.4.8, 2.1.1, 2.1.2, 2.1.4, 2.1.6, 2.1.7, 2.1.8,
  1566.      2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
  1567. Appeal chain  9.5
  1568. Appointment of coordinators  1.2.3, 1.2.4, 5.7, 6.1
  1569. Availability of NodeList  1.3.4
  1570. Balloting Period  8.4
  1571. Bombing run  4.2
  1572. BossNode  1.2.1.2
  1573. Boundaries  1.3.2
  1574. Business use of FidoNet  1.3.6
  1575. Calling areas  1.3.2, 5.6, 5.7
  1576. Case histories  9.10, 10.3
  1577. Chain of command  1.2.8
  1578. Changing node numbers  4.3, 5.2
  1579. Checks and balances  1.2.8
  1580. Commercial messages  1.3.6, 2.1.4, 4.2
  1581. Complaint (policy)  2.1.6.1, 9
  1582. Contributions to FidoNews  1.3.1
  1583. Current nodelist  2.1.11
  1584. Daylight Savings Time  2.1.14
  1585. Difference file  4.5, 5.8, 8.2
  1586. Disclosing private mail  2.1.6
  1587. Discussion period  8.2
  1588. Disputes  9
  1589. Distribution of ballots  8.2
  1590. Down  2.3, 4.4, 5.5
  1591. Downloading by users  3.6, 4.5, 5.8
  1592. EchoMail  4.2, 9.9
  1593. Effective date (policy change)  8.2
  1594. Election of coordinators  1.2.5, 6.2, 7.2
  1595. Eligibility to vote  8.3
  1596. Encryption  2.1.4, 4.2
  1597. Exceptions  5.6
  1598. Excessively annoying behavior  1.2.1.1, 1.3.5, 2.1.1, 2.1.2, 2.1.4, 2.1.6,
  1599.      2.1.7, 2.1.8, 2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
  1600. Exclusivity of Zone Mail Hour  2.1.8
  1601. Excommunication  2.1.12, 4.3, 5.2, 9
  1602. Exemptions, node location  1.3.2, 5.6
  1603. Familiarity with policy  2.1.2, 2.2
  1604. FidoNews  1.3.1
  1605.      availability 3.1, 4.5, 5.8
  1606. FTSC  2.1.8, 2.1.9, 2.4
  1607. Gateway  2.1.3
  1608. Geography  1.3.2, 5.6
  1609. Glue  4.5
  1610. Guarantee of mail delivery  1.3.6
  1611. Hats  3.4
  1612. Host-routed mail  4.2
  1613. How to obtain a node number  2.2
  1614. Hub  1.2.3.1, 4.4
  1615. Illegal behavior  2.1.1, 9.6
  1616. Illegal mail  4.2
  1617. Impeachment  8.7
  1618. In-transit mail  2.1.6.1
  1619. Independent node  4.2, 5.2
  1620. Inter-zonal questions  1.2.6
  1621. International Coordinator  1.4.1, 1.4.9, 7
  1622. Justification of private nodes  2.1.9
  1623. Language  1.0
  1624. Levels of FidoNet  1.2, 1.4
  1625. Local calling areas  1.3.2
  1626. Local policies  1.2, 3.3
  1627. Mail  1.2.3, 4.2
  1628. Mailer  2.2
  1629. Majority  8.6, 8.7.2
  1630. Member of area administrated  3.5
  1631. Modem  2.2
  1632. Modification of mail  2.1.5
  1633. National Mail Hour  see Zone Mail Hour
  1634. Network
  1635.      advantages 2.2
  1636.      boundaries 1.3.2, 5.4
  1637.      definition 1.2.3
  1638.      forming 2.4, 5.3
  1639.      hub 1.2.3.1, 4.4
  1640.      numbers 2.2, 5.4
  1641. Network Coordinator  1.2.3
  1642.      procedures 4
  1643.      replacement 5.7, 9.3
  1644. Network Mail Hour  see Zone Mail Hour
  1645. New sysops  2.1.2, 3.6
  1646. Node numbers  4.3, 5.2
  1647.    obtaining  2.2
  1648. Nodelist  1.3.4, 2.2, 4.4, 5.5
  1649.      availability 3.1, 4.5, 5.8
  1650.      changes 4.4, 5.2
  1651.      current 2.1.11
  1652.      definition 1.3.4
  1653.      format 10.3
  1654.      official 1.3.4
  1655. Nodes
  1656.      definition 1.2.1
  1657.      down 2.3
  1658. Observing mail events  2.1.8, 2.1.10
  1659. Obtaining a node number  2.2
  1660. Offensive messages  2.1.5
  1661. Orders (commercial)  1.3.6
  1662. Partial nodelist  1.3.4
  1663. Pirated software  2.1.1
  1664. Point of origin  2.1.3
  1665. Points  1.2.1.2, 2.1.3
  1666. Policy  3.1, 3.3, 4.5, 5.8
  1667.      changing 8
  1668.      complaint 2.1.6.1, 9
  1669.      familiarity with 2.1.2, 2.2
  1670.      local 1.2, 3.3
  1671. Precedent  3.7, 9.10, 10.3
  1672. Private messsages  2.1.6
  1673. Private network  1.2.1.2
  1674. Private nodes  2.1.9
  1675. Problem resolution  9
  1676. Protocol  2.1.8
  1677. Public BBS  3.6
  1678. Ratification  7.1
  1679. Redundant nodes  2.1.9
  1680. Referendum  1.2.7, 8
  1681. Regional Coordinator  1.2.4
  1682.      procedures 5
  1683.      replacement 6.1, 9.4
  1684. Regions  1.2.4
  1685. Replacement of coordinators  1.2.8
  1686. Replacing services  3.4
  1687. Requirements to be in NodeList  1.3.4, 2.1.2, 2.2
  1688. Resignation of ZC  8.7.4
  1689. Resolution of disputes  9
  1690. Results Announcement  8.2
  1691. Review of decisions  3.7
  1692. Review of routed traffic  2.1.4
  1693. Routing  2.1.4 - 2.1.7, 4.2
  1694. Routing Hub  1.2.3.1, 4.4
  1695. Rules  9.1
  1696. Speedy decision  9.7
  1697. Standards (FTSC)  2.1.8, 2.4
  1698. Statute of limitations  9.6
  1699. Submissions to FidoNews  1.3.1
  1700. Sysop procedures  2
  1701. System operator (sysop)  1.2.1
  1702. Three-tiered networks  1.2.3.1
  1703. Time limit on decision  9.7
  1704. Timing of Zone Mail Hour  2.1.13, 2.1.14, 10.2
  1705. Top-down  1.4.9
  1706. Tradition  3.7
  1707. Trivial network  5.3
  1708. Unattended systems  2.3
  1709. Updates to nodelist  3.2
  1710. User  1.2.1.1
  1711. User access during ZMH  2.1.8
  1712. Vacation  2.3
  1713. Voice telephone number  2.2
  1714. Vote  8
  1715.      eligibility 8.3, 8.7.2
  1716. ZMH see Zone Mail Hour
  1717. Zone Coordinator  1.2.5, 6
  1718.      election 6.2
  1719.      impeachment 8.7
  1720.      procedures 6
  1721.      removal 6.2
  1722.      resignation during impeachment 8.7.4
  1723. Zone Coordinator Council  1.2.6, 7.1
  1724. Zone Mail Hour  1.3.3, 2.1.8
  1725.      timing 2.1.13, 2.1.14, 10.2
  1726. Zones  1.2.5, 1.3.2
  1727.